Тем из вас, у кого скопилось несколько сотен лишних долларов в это непростое время, компания VMware предлагает приобрести подписку на новый обучающий сервис - VMware Learning Zone. Данный сервис позволяет получить доступ к платным обучающим видеороликам на базе годовой подписки в режиме 24/7:
Платная подписка VMware Learning Zone позволяет:
Смотреть обучающие видеоролики и туториалы по последним продуктам и технологиям VMware.
Искать в библиотеке платных видеороликов нужные материалы.
Получать информацию о решении проблем, развертывании решений и их настройке в рамках курсов уровня "deep dive".
Получать доступ к курсам с мобильных устройств, а также принимать участие в обсуждениях сообществ, помогающих решать проблемы, возникающие в процессе эксплуатации решений VMware.
В рамках подписки на данный момент доступны курсы по следующим темам:
Deep Dive: VMware Directory Services (vmdir) Database
Disaster Recovery
ESXi: Network Troubleshooting at the ESXi Command Line
VMware Cloud Automation Center 6.0
Configuring vCenter Single Sign-On
vCenter Site Recovery Manager
vCenter
vCloud Air: Connecting your Data Center To vCloud Air - Tips and Techniques
vCloud Suite: Up to Speed - vCloud Director Rest API for Beginners
Virtual Machine Disk (VMDK) Snapshots
Virtual SAN Troubleshooting
VMRC and Media Upload Troubleshooting
VMware Horizon 6
Virtual SAN 5.5
vSphere Managed Object Browser
Ну и главное - цена. Если считать по курсу на 31 декабря этого года, то получается что-то около 80 тысяч рублей за годовую подписку:
Купить годовой доступ к VMware Learning Zone можно по этой ссылке.
Как знают многие администраторы VMware vSphere, в инфраструктуре хранилищ иногда возникает проблема выравнивания виртуальных дисков машин (последний раз мы писали об этом тут). Некорректное выравнивание блоков может возникать на двух уровнях - гостевой ОС по отношению к VMFS и VMFS по отношению к блокам дискового массива:
В целом-то, эта проблема не очень актуальна в последнее время, учитывая что в последних версиях VMware vSphere и ОС Windows с этим вполне разобрались. Однако для тех, у кого инфраструктура очень древняя (особенно с ВМ на базе Windows 2003 и 2008), пережила несколько апгрейдов и миграций - выравнивание блоков проверить было бы нелишним.
Именно для этого и была выпущена бесплатная утилита VM Check Alignment. Утилита старенькая, но вполне себе работает для Windows 2003/2008 и Windows Vista/7:
В параметре Starting Offset мы видим, что виртуальный диск выровнен корректно, и никаких изменений не требуется. Для некорректно выровненных дисков, кстати, производительность хранилищ может падать на величину до 10%.
О том, как нужно выравнивать блоки виртуальных дисков написано тут и тут.
Компания VMware выпустила еще один интересный документ, описывающий референсную архитектуру программно-определяемого датацентра (SDDC) - "Creating a VMware Software-Defined Data Center".
В данном документе на 29 страницах приводится пример создания корпоративной инфраструктуры на базе следующих продуктов:
Описание программных компонентов для построения SDDC-инфраструктуры
Обзор референсной архитектуры
Информация об оборудовании и аппаратных компонентах
Детальная информация о компонентах Software-Defined Data Center
Высокоуровневая конфигурация инфраструктуры SDDC
В рассматриваемой архитектуре есть три основных модуля:
Management Cluster - основной кластер управления и мониторинга, в котором работают такие средства как vCenter, Log Insight и прочие. Состоит минимум из трех хост-серверов ESXi.
Edge Cluster - отдельный кластер для управления сетевым взаимодействием. Он упрощает конфигурацию физической сети передачи данных путем создания абстракции физического сетевого стека в ИТ-инфраструктуре. Также содержит минимально 3 хоста.
Payload Cluster - "рабочая лошадка" виртуальной инфраструктуры, кластер, где крутятся рабочие нагрузки. Может масштабироваться "подами" (pods) по мере роста потребностей предприятия.
В целом документ весьма интересный, так как в комплексе затрагивает управляющие компоненты виртуальной инфраструктуры и показывает работу средств управления большой виртуальной средой, а также то, каким образом эти средства решают возникающие в такой инфраструктуре проблемы.
Ниже мы приведем еще один аргумент в пользу того, чтобы не создавать снапшоты виртуальных машин на постоянной основе (во временном их использовании нет ничего плохого).
Итак, в одной из статей мы писали про расширенную настройку VMFS Heap Size (размер кучи), которая косвенно определяет максимально доступный объем хранилищ на хосте.
Также мы писали о том, что параметр VMFS3.MaxHeapSizeMB еще в VMware vSphere 5.1 был увеличен до 640 МБ.
Однако есть и куча для механизма "Copy-on-Write" (COW), которая определяется расширенной настройкой COW.COWMaxHeapSizeMB - она ограничивает число одновременно запущенных на хосте виртуальных машин. Механизм COW работает на хосте, когда у машины есть снапшоты (дельта-диски).
По умолчанию это значение равно 192 МБ, но может быть увеличено до 256 МБ:
Также этот параметр можно узнать из командной строки:
~ # esxcfg-advcfg -g /COW/COWMaxHeapSizeMB
Value of COWMaxHeapSizeMB is 192
И установить его в максимальное значение:
~ # esxcfg-advcfg -s 256 /COW/COWMaxHeapSizeMB
Value of COWMaxHeapSizeMB is 256MB
Давайте посмотрим, как расходуется пространство этой кучи на хосте, в зависимости от параметров виртуальных машин на нем. Вот тут есть такая интересная формула:
X - это максимальное число запущенных виртуальных машин на хосте,
COW_HEAP_SIZE - размер кучи в байтах,
B - размер виртуального диска в байтах,
2 * 1048576 - это GDE Coverage (хз, что такое),
4 - это число байт на Root Entry,
S - число снапшотов каждого из виртуальных дисков,
Y - число дисков у машин.
Возьмем для примера машину с 5 дисками размером в 80 ГБ по 6 снапшотов у каждого при максимальном размере кучи в 256 МБ. Получим, что таких машин может быть запущено на хосте:
Это примерно около 40 машин (всего лишь) - при максимально доступном размере кучи на VMware ESXi. Понятно дело, что мало где можно найти машины с 5 дисками, у каждого из которых по 6 снапшотов, но я видел подобные конфигурации пару раз.
Нетрудно понять, как в этой формуле влияют снапшоты на максимальное число запущенных виртуальных машин. Поэтому повторим еще раз: постоянные снапшоты - зло.
Как многие из вас знают, у компании VMware есть бесплатный продукт VMware vSphere Hypervisor, который в народе называется VMware ESXi Free. Многие начинающие администраторы, услышав, что ESXi бесплатен, устанавливают его, но забывают накатить лицензию, которую надо скачивать с портала My VMware. Без этого бесплатный VMware ESXi будет работать в режиме пробной версии 60 дней...
Многие администраторы устанавливают VMware Tools с помощью vSphere Client, который предоставляет идущую в дистрибутиве версию этого пакета. Однако не все знают, что VMware Tools можно скачать по прямой ссылке из репозитория VMware, затем положить exe-файл на файловый сервер (если у вас гостевая ОС Windows) и запускать на всех виртуальных машинах.
Последняя версия тулзов всегда находится по этой ссылке:
Но эти пакеты доступны только для следующих версий гостевых ОС:
Community ENTerprise Operating System (CentOS) - версии с 4.0 по 6.x
Red Hat Enterprise Linux версии с 3.0 по 6.x
SUSE Linux Enterprise Server версии 9 по 11
SUSE Linux Enterprise Desktop версии 10 по 11
Ubuntu Linux версии с 8.04 по 12.04
Надо отметить, что доступные в репозитории пакеты содержат компоненты VMware Tools, начиная еще с версий ESX 3.5. Но с версии vSphere 4.1 все они стали обратно совместимы - вы можете скачать последнее обновление VMware Tools и накатить его на любую версию vSphere 4.x или 5.x.
Кроме того, если в списке остутствуют необходимые ОС Linux, то можно воспользоваться пакетом Open VM Tools, которые являются открытой версией VMware Tools и рекомендованы к распространению вендорами платформ. Например, вот тут указано, как нужно ставить Open VM Tools в гостевых ОС RHEL 7.
Как установить IP-параметры HP iLO через консоль сервера VMware ESXi.
При развертывании инфраструктуры VMware vSphere на базе серверов HP всегда требуется задать параметры IP-идентификации для интерфейса удаленной консоли iLO. Обычно это делается в настройках сервера, но удобнее сделать это из консоли ESXi, если вы используете кастомизированную сборку ESXi под HP (а ее надо использовать, так как некоторые девайсы могут просто не работать, поскольку в стандартной сборке под них нет драйверов).
Для начала откроем на хосте ESXi доступ по SSH в разделе Security Profile, стартовав соответствующий сервис:
Заходим на хост по SSH и переходим в папку с утилитами HP:
cd /opt/hp/tools
Копируем настройки HP iLO в файл XML:
./hponcfg -w ilo.xml
Далее этот файл нам нужно отредактировать, для этого можно использовать WinSCP или Veeam FastSCP.
Копируем iLO.xml к себе локально:
Открываем его в текстовом редакторе и правим секции, помеченные красным:
<!-- HPONCFG VERSION = "4.0-13.0" -->
<!-- Generated 11/11/2014 23:37:47 -->
<RIBCL VERSION="2.1">
<LOGIN USER_LOGIN="Administrator" PASSWORD="password">
<DIR_INFO MODE="write">
<MOD_DIR_CONFIG>
<DIR_AUTHENTICATION_ENABLED VALUE = "N"/>
<DIR_LOCAL_USER_ACCT VALUE = "Y"/>
<DIR_SERVER_ADDRESS VALUE = ""/>
<DIR_SERVER_PORT VALUE = "636"/>
<DIR_OBJECT_DN VALUE = ""/>
<DIR_OBJECT_PASSWORD VALUE = ""/>
<DIR_USER_CONTEXT_1 VALUE = ""/>
<DIR_USER_CONTEXT_2 VALUE = ""/>
<DIR_USER_CONTEXT_3 VALUE = ""/>
</MOD_DIR_CONFIG>
</DIR_INFO>
<RIB_INFO MODE="write">
<MOD_NETWORK_SETTINGS>
<SPEED_AUTOSELECT VALUE = "Y"/>
<NIC_SPEED VALUE = "100"/>
<FULL_DUPLEX VALUE = "N"/> <IP_ADDRESS VALUE = "192.168.16.33"/>
<SUBNET_MASK VALUE = "255.255.255.0"/>
<GATEWAY_IP_ADDRESS VALUE = "192.168.16.254"/>
<DNS_NAME VALUE = "ESX01-iLO"/>
<PRIM_DNS_SERVER value = "192.168.16.1"/>
<DHCP_ENABLE VALUE = "N"/>
<DOMAIN_NAME VALUE = "educ.local"/>
<DHCP_GATEWAY VALUE = "Y"/>
<DHCP_DNS_SERVER VALUE = "Y"/>
<DHCP_STATIC_ROUTE VALUE = "Y"/>
<DHCP_WINS_SERVER VALUE = "Y"/>
<REG_WINS_SERVER VALUE = "Y"/>
<PRIM_WINS_SERVER value = "0.0.0.0"/>
<STATIC_ROUTE_1 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_2 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_3 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
</MOD_NETWORK_SETTINGS>
</RIB_INFO>
<USER_INFO MODE="write">
</USER_INFO>
</LOGIN>
</RIBCL>
Копируем измененный файл обратно на хост ESXi (предыдущий сохраните - просто переименуйте) и выполняем команду заливки конфигурации:
./hponcfg -f ILO.xml
Дождитесь успешного выполнения команды - и можно коннектиться к iLO через веб-браузер по новому адресу. Этот способ удобен тем, что можно не перезагружать сервер.
Многие пользователи VMware Virtual SAN (VSAN), когда проводят тест бэкапа одной виртуальной машины, замечают, что время резервного копирования этой ВМ существенно больше, чем таковое для машины, размещенной на дисковом массиве.
Дункан в своем блоге подробно разбирает эту проблему. Тут дело вот в чем - когда вы используете дисковый массив, то виртуальная машина "размазывается" по дискам RAID-группы, что позволяет читать одновременно с нескольких дисков. Это дает хорошую производительность операции резервного копирования для одной машины.
Кластер же VSAN работает немного по-другому. Это объектное хранилище, в котором виртуальный диск ВМ хранится на одном хосте и его реплика существует на втором. Кроме этого, есть кэш на SSD-диске (но его еще нужно "прогреть"). То есть выглядит все это следующим образом:
Соответственно, при бэкапе одной виртуальной машины данные читаются только с двух HDD-дисков, а не с нескольких как в традиционной архитектуре дисковых массивов, при этом сам кластер VSAN может состоять из нескольких хостов (до 32 узлов). То есть, это архитектурное ограничение.
Однако если мы будем делать одновременный бэкап нескольких виртуальных машин с хранилища Virtual SAN время этой операции уже будет сравнимо с дисковым массивом, поскольку будет задействовано сразу несколько дисков на каждом из хостов, плюс хорошо прогреется кэш. Поэтому проведение такого теста (ведь он ближе к реальным условиям) и было бы более показательным при сравнении Virtual SAN и традиционных хранилищ.
То же самое относится и к VDI-инфраструктуре на базе VSAN - многие пользователи отмечают, что первая фаза операции Recompose (когда создается реплика - полный клон ВМ) отрабатывает весьма медленно. Однако если вы делаете много таких операций - кэш прогревается, и одновременное создание нескольких клонов начинает работать заметно быстрее в расчете на одну машину.
Многие пользователи в целях безопасности хотят отключить использование USB-портов на хостах VMware ESXi - а то кто-нибудь зайдет в серверную комнату и утащит данные на диске.
К сожалению, на текущих версиях платформы VMware vSphere сделать этого нельзя. Можно, конечно, отключить USB Arbitrator service следующей командой (как написано вот тут):
/etc/init.d/usbarbitrator stop
Но это лишь отключит проброс USB-устройств в виртуальные машины, при этом само устройство (например, /dev/usb0101) отключено не будет. Поэтому, тут остается два решения:
Отключить USB-устройства в BIOS - но это поддерживают не все производители железа.
Мониторить использование локальных USB-устройств и слать алерты менеджеру по ИБ.
Второй вариант можно реализовать с помощью продукта VMware vRealize Log Insight, который позволяет мониторить логи хостов ESXi и слать по ним алерты при их появлении и повторении. Вот, например, в выводе этого лога мы видим, что кто-то подключал USB-девайс к хосту:
Сопоставив время этих событий и время посещения конкретными людьми датацентра, мы поймем, кто пытался или сделал что-то нехорошее. Решение, конечно, не ахти, но какое уж есть.
Бывают такие ситуации, когда у вас в руках только мобильный телефон, с которого возникает необходимость перезагрузить виртуальную машину на хосте VMware ESXi. Например, у вас в инфраструктуре что-то случилось, но вы имеете доступ к ней через VPN со своего айфона.
Если у вас есть доступ по SSH, то проблему решить весьма просто, как это описано вот тут (а также в KB 1014165). Скачиваем бесплатное приложение Server Auditor по этой ссылке (если у вас андроид - то по этой).
Далее заходим на свой хост ESXi по SSH и выполняем команду:
esxcli vm process list
Будет выведен список всех процессов виртуальных машин, где нам нужно найти World ID нужной машины. Записываем или запоминаем его.
Далее убиваем виртуальную машину командой (вместо параметра force можно использовать hard и soft для выключения ВМ):
esxcli vm process kill -t force -w WorldID
Выглядит это примерно вот так:
Далее снова выполняем команду esxcli vm process list, чтобы убедиться, что виртуальная машина теперь выключена.
Теперь запоминаем VMID нашей виртуальной машины, который можно получить с помощью команды:
vim-cmd vmsvc/getallvms
Если помните часть имени ВМ, можно искать с помощью grep:
vim-cmd vmsvc/getallvms |grep <текст в имени ВМ>
Найдя VMID, проверяем дополнительно, что она выключена:
vim-cmd vmsvc/power.getstate <vmid>
Теперь включаем виртуальную машину:
vim-cmd vmsvc/power.on <vmid>
Вот и все, потом обязательно нужно проверить, что машина включилась, естественно - сначала в списке процессов, а потом пингом.
Некоторое время назад мы писали о технологии VMware vFlash (она же Virtual Flash), которая позволяет использовать высокопроизводительные накопители SSD (вот тут - о производительности) для решения двух важных задач:
Предоставление виртуальным машинам дополнительного места, в которое будут свопиться страницы памяти в случае недостатка ресурсов на хосте (это намного более производительно, чем свопить на обычный HDD-диск). Эта техника называется Virtual Flash Host Swap и пришла на смену механизму Swap to SSD.
Прозрачное встраивание в поток ввода-вывода на хосте между виртуальными машинами и хранилищами, что позволяет существенно ускорить операции чтения данных виртуальных дисков. Называется это VMware Flash Read Cache (vFRC).
Ниже мы вкратце расскажем о настройке этих двух механизмов через VMware vSphere Web Client (в обычном C#-клиенте этого, к сожалению, нет). Если что, более подробно о технике vFRC можно почитать по этой ссылке.
Итак, в vSphere Web Client переходим на вкладку "Manage" для нужного хоста, далее в разделе "Settings" выбираем пункт "Virtual Flash Resource Management". Это кэш, который мы добавляем для того, чтобы в случае нехватки места, его могли использовать виртуальные машины, чтобы не свопить данные на медленный магнитный диск, кроме того он же будет использоваться для целей vFRC.
Нажимаем Add Capacity:
Выбираем диски, которые мы будем использовать как Host Swap и нажимаем "Ок" (все данные на них будут стерты):
Всего под нужды Virtual Flash может быть выделено до 8 дисков суммарной емкостью до 32 ТБ. Видим, что ресурс добавлен как Virtual Flash Resource (его емкость отдельно учитывается для vFRC и Host Cache):
Настройка Virtual Flash Host Swap
Первым делом рекомендуется настроить именно этот кэш, а остаток уже распределять по виртуальным машинам для vFRC.
Выбираем пункт "Virtual Flash Host Swap Cache Configuration" в левом меню, а далее в правой части мы нажимаем кнопку "Edit":
Указываем необходимый объем, который планируется использовать, и нажимаем "Ок":
После того, как мы настроили нужное значение - в случае недостатка ресурсов на хосте виртуальные машины будут использовать высокоскоростные диски SDD для своих нужд внутри гостевой ОС (файлы подкачки прочее).
Настройка VMware Flash Read Cache (vFRC)
Напомним, что это кэш только на чтение данных, операции записи будут производиться на диск, минуя флэш-накопители. Соответственно, такой кэш улучшает производительность только операций чтения.
Сам кэш vFRC можно настроить на уровне отдельных виртуальных машин на хосте VMware ESXi, а также на уровне отдельных виртуальных дисков VMDK.
Чтобы выставить использование нужного объема vFRC для отдельной виртуальной машины, нужно выбрать пункт "Edit Settings" из контекстного меню ВМ и на вкладке "Virtual Hardware" в разделе "Virtual Flash Read Cache" установить нужное значение для соответствующего виртуального диска:
Если этого пункта у вас нет, то значит у вас версия виртуального "железа" (Virtual Machine Hardware) ниже, чем 10, и ее нужно обновить.
По ссылке "Advanced" можно настроить размер блока для кэша (значение Reservation, установленное тут, обновит значение на предыдущем скрине):
Ниже приведем ссылки на статьи VMware Knowledge Base (взято отсюда), где можно узнать о расположении и назначении файлов журнала (логов) для различных продуктов, включая компоненты решения VMware vSphere.
Четыре с половиной года назад мы писали про то, что у технологии Transparent Page Sharing (TPS), которая по-умолчанию используется в VMware vSphere, нет будущего. Напомним, что TPS - это механизм поиска и удаления дубликатов страниц памяти в целях экономии физического пространства RAM (вместо самой дублирующейся страницы хранится ссылка на нее).
Технолония потеряла актуальность, когда вовсю стали применяться большие страницы памяти (Large Memory Pages), для которых размер страницы равен 2 МБ, а значит вероятность появления двух полностью одинаковых страниц очень низка.
Более подробно о проблемах с TPS написано вот в этой статье на блогах VMware.
Если же вы хотите отключить этот механизм уже прямо сейчас, то нужно сделать следующее:
Залогиниться на ESX\ESXi или vCenter Server через vSphere Client.
Выбрать нужный хост и зайти на вкладку Configuration, затем перейти в Advanced Settings в секции Software.
Выбираем раздел Mem и в нем устанавливаем значение параметра Mem.ShareScanGHz в 0.
После патча и обновлений ESXi механизм TPS можно будет включить следующим образом (Advanced Settings в секции Software):
Параметр Mem.ShareForceSalting (включение TPS на уровне всего хоста ESXi). Если значение стоит 0 - то значит TPS по-прежнему работает на хосте, если 1 - механизм отключен.
Параметр sched.mem.pshare.salt (ставится на уровне ВМ) позволяет включать/отключать TPS для отдельных виртуальных машин (например, старые Windows или линуксы - для них можно было бы включить). Когда параметр ShareForceSalting установлен в значение 1, то для нуждающихся в TPS машин в их Advanced Configuration нужно установить одинаковые значения "соли". Без этого TPS не работает - соответственно, он отключен.
Часто пользователям требуется информация о том, какому номеру билда соответствует версия продукта от VMware (такое бывает нужно, например, для VMware vSphere / ESXi, vCenter, vCenter Server Appliance). К тому же, иногда бывает полезно узнать, когда вышла та или иная версия продукта.
Поэтому мы взяли из этого поста информацию о продуках, датах релиза и номерах версий, чтобы можно было всегда обращаться к этому посту у нас.
Новая архитектура сервисов управления VMware vCenter в VMware vSphere 6.
Некоторое время назад мы писали о новых возможностях платформы виртуализации VMware vSphere 6, о которых было подробно рассказано на прошедшей конференции VMworld 2014. Одним из нововведений новой версии станет новая архитектура сервисов управления VMware vCenter.
Надо начать с того, что "толстый" десктопный клиент vSphere Client в vSphere 6 по-прежнему останется доступен для управления виртуальными машинами через vCenter. Причины просты - компании VMware так и не удается довести до ума Web Client - он все еще притормаживает и не настолько быстро обновляет статус объектов, как это делает обычный vSphere Client. Однако все новые возможности будут появляться только в vSphere Web Client.
С точки зрения самого vCenter появляется новый сервис Platform Services Controller (PSC), который заменяет существующие сервисы Single Sign-On (напомним, что они уже были переписаны в версии SSO 5.5). Если ранее SSO был частью vSphere и обновлялся только вместе с платформой, то теперь PSC может быть обновлен отдельно (например, если появились новые источники аутентификации или были исправлены ошибки), что очень удобно.
На картинке ниже Infrastructure Controller (это так сейчас в бете называется Platform Services Controller) может быть выделен для каждого сервиса vCenter, но также и несколько сервисов vCenter могут использовать один PSC.
В обоих случаях сохраняются функции синхронизации данных между контроллерами и механика их отказоустойчивости.
Помимо стандартных функций аутентификации SSO, компонент PSC возьмет на себя управление лицензиями, а также хранение сертификатов.
Когда у вас до 8 серверов vCenter в рамках одной географической площадки, то можно использовать один PSC (который устанавливается на том же хосте, где и один из серверов vCenter). Ну а если у вас несколько датацентров, то для каждого разумнее использовать свой PSC, к которому подключаются не только сервисы vCenter, но и другие компоненты виртуальной инфраструктуры, например, продукт для управления облачной инфраструктурой VMware vCAC или средства автоматизации vRealize Orchestrator (бывший vCenter Orchestrator):
Шестую версию vCenter уже настоятельно рекомендуют устанавливать в виртуальной машине, так как только тогда можно будет воспользоваться преимуществами технологий отказоустойчивости и непрерывной доступности VMware HA и VMware Fault Tolerance. Ранее был продукт и для физических серверов - vCenter Heartbeat, но его сняли с производства.
Настало время объединить все сервисы управления виртуальной средой (vCenter, серверы vCAC, vCenter Log Insight, vCenter Orchestrator, vCenter Operations Manager и т.п.) в виде блоков в виртуальных машинах:
Также весьма существенно будет доработан виртуальный модуль vCenter Server Appliance (vCSA). Теперь он будет поддерживать до 1 000 серверов ESXi под своим управлением, 10 000 включенных виртуальных машин, 64 хоста ESXi на кластер HA/DRS, 6 000 ВМ в кластере, а также 10 серверов vCenter в режиме Linked Mode.
Как многие из вас знают, ранее режим Linked Mode не поддерживался со стороны vCSA, так как для этого режима использовалась модель Active Directory Application Mode (ADAM), не поддерживаемая в Linux. Теперь для Linked Mode используется собственная аутентификация, поэтому объединение нескольких машин vCSA в единую мета-сущность теперь вполне возможно.
Как Windows-версия, так и vCSA будут использовать встроенную БД vPostgres, а в качестве внешних БД стандартно будут поддерживаться Microsoft SQL Server и Oracle.
Ну и, помимо всего прочего, сейчас ходят слухи о выпуске вместе с VMware vSphere 6 утилиты для миграции с Windows-версии vCenter на vCSA. Эта штука для многих пользователей будет очень кстати.
ИТ-ГРАД запускает новую облачную площадку в дата-центре SDN. Перед переводом площадки в промышленную эксплуатацию мы должны убедиться в том, что все ее компоненты работают как задумывалось, а дублирование и обработка аппаратных сбоев происходит в штатном режиме. Для проверки работоспособности новой облачной площадки был разработан план тестирования, с которым вам и предлагаем ознакомиться.
Немного о наполнении новой площадки:
На первом этапе в новый ЦОД была установлена система хранения данных NetApp FAS8040 (мы как золотой партнер компании NetApp – остаемся верны вендору), система пока имеет 2 контроллера FAS8040, которые собраны в кластер через дублируемые 10Gbit/s коммутаторы (Cluster Interconnects) и позволяют наращивать кластер СХД до 24 контроллеров. Контроллеры СХД в свою очередь подключены к сети ядру сети по 10Gbit/s оптическим линкам сформированое двумя коммутаторами Cisco Nexus 5548UP с поддержкой L3.
Серверы гипервизоров VMware vSphere ESXi (Dell r620/r820) подключаются к сети по двум интерфейсам 10Gbit/s, используя конвергентную среду передачи данных (для работы с дисковым массивом и сетью передачи данных). Пул ESXi серверов образует кластер с поддержкой VMware vSphere High Availability (HA). Менеджмент интерфейсы серверов iDRAC и контроллеров СХД собираются на отдельном выделенном коммутаторе Cisco.
Когда базовая настройка инфраструктуры фактически была завершена настало время остановиться и оглядеться назад: ничего не забыли? все ли работает? надежно?
Задел на успех в лице опытных инженеров мы уже имеем, но чтобы «фундамент» оставался крепким, необходимо, конечно же, правильно провести испытания на стрессоустойчивость инфраструктуры. Успешное окончание тестов будет свидетельствовать о завершении первого этапа и сдачи приемо-сдаточных испытаний (ПСИ) новой облачной площадки.
Итак, озвучу «исходные данные» и «план тестирования». А внимательные читатели, которым не чужда судьба ИТ-ГРАДа, могут внести предложения/рекомендации/пожелания возможных моментов, которые мы могли не предусмотреть. С радостью их выслушаем.
«Исходные данные»:
FAS8040 dual controller под управлением Data ONTAP Release 8.2.1 Cluster-Mode
Коммутаторы ядра унифицированной сети Cisco Nexus 5548 – 2 шт.
Пограничный роутер Juniper MX80 (пока один, второй ещё не приехал).
Управляемый коммутатор Cisco 2960.
Серверы Dell PowerEdge R620/R810 with VMware vSphere ESXi 5.5.
Схема подключения выглядит следующим образом:
Нарочно не стал рисовать менеджмент свитч и Juniper MX80, т.к. связность интернет будем тестировать после резервирования канала, не хватает ещё одного Juniper MX80 (ждем к концу месяца).
Итак, условно наши «краш-тесты» можно поделить на 3 вида:
Тестирование дискового массива FAS8040;
Тестирование сетевой инфраструктуры;
Тестирование виртуальной инфраструктуры.
При этом тестирование сетевой инфраструктуры в нашем случае выполняется в укороченном варианте по причинам, которые я указывал выше.
Перед тестами планируется ещё раз сделать бэкапы конфигураций сетевого оборудования и массива, а также проанализировать результаты дискового массива с помощью Config Advisor.
Теперь давайте расскажу подробнее о плане тестирования.
I. Удаленное тестирование
Поочередное выключение контроллеров FAS8040.
Ожидаемый результат: автоматический takeover на рабочую ноду, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
Поочередное отключение всех Cluster Link одной ноды.
Ожидаемый результат: автоматический takeover на рабочую ноду, либо перемещение/переключение VSM на доступные сетевые порты на второй ноде, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
Отключение всех Inter Switch Link между свичами CN1610.
Ожидаемый результат: предполагаем, что кластерные ноды будут доступны друг для друга через cluster links одного из Cluster Interconnect (в связи с перекрестным соединением NetApp — Cluster Interconnect).
Перезагрузка одного из Nexus.
Ожидаемый результат: один из портов на нодах должен оставаться доступным, на IFGRP интерфейсах на каждой ноде должен оставаться доступен один из 10 GbE интерфейсов, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
Поочередное гашение одного из vPC (vPC-1 или vPC-2) на Nexus.
Ожидаемый результат: перемещение/переключение VSM на доступные сетевые порты на второй ноде, все ресурсы VSM должны быть доступны на ESXi, доступ к датасторам не должен пропадать.
Поочередное отключение Inter Switch Link между коммутаторами Cisco Nexus 5548.
Ожидаемый результат: Port Channel активен на одном линке, нет потери связности между коммутаторами.
Поочередное жесткое отключение ESXi.
Ожидаемый результат: отработка HA, автоматический запуск ВМ на соседнем хосте.
Слежение за отработкой мониторинга.
Ожидаемый результат: получение нотификаций от оборудования и виртуальной инфраструктуры о появившихся проблемах.
II. Непосредственно на стороне оборудования
Отключение кабелей питания (все единицы оборудования).
Ожидаемый результат: оборудование работает на втором блоке питания, нет проблем с переключением между блоками.
Замечание: Менеджмент свитч Cisco не имеет резервирования питания.
Поочередное отключение сетевых линков от ESXi (Dell r620/r810).
Ожидаемый результат: ESXi доступен по второму линку.
На днях компания VMware выпустила очень полезный для администраторов виртуальных инфраструктур документ VMware Horizon 6 Reference Architecture на 53 страницах, в котором приведена типовая конфигурация VDI-среды на 2000 виртуальных ПК, расширяемая до 10 000 пользователей в случае необходимости.
В документе рассмотрена архитектура на базе серверной инфраструктуры Supermicro и хранилища EMC VNX 5500. На данной конфигурации удалось добиться следующих результатов:
Конфигурация программно-аппаратного комплекса:
Хосты ESXi с процессорами 2.1 ГГц Intel E5-2658 или 2.9 ГГц E5-2690
128 ГБ RAM на один хост ESXi
Хранилище для виртуальных ПК EMC VNX5500 на базе протокола NFS (20 ТБ)
Сетевое оборудование 10 Gigabit Ethernet (GbE)
Виртуальные машины Windows 7 с одним vCPU и 1GB vRAM (типовая "легкая" пользовательская нагрузка)
Виртуальные машины с ролью Microsoft Remote Desktop Session Host (RDSH) с четырьмя vCPU и 24 ГБ RAM
ПО VMware Horizon 6 на платформе VMware vSphere 5.5
А вот собственно и сама аппаратная конфигурация описанной в документе архитектуры:
В качестве составляющих программной среды используются все компоненты решения VMware Horizon 6 (View, Mirage 5.0 и Workspace Portal 2.0), работающие на платформе VMware vSphere 5.5.
Документ очень насыщен техническими деталями и рекомендуется к прочтению всем тем, кто планирует масштабное развертывание инфраструктуры виртуальных и физических ПК на базе семейства решений VMware Horizon 6.
Не так давно мы писали о новых возможностях лидирующей на рынке платформы виртуализации VMware vSphere 6, которая на данный момент доступна в публичной бета-версии.
Одной из новых возможностей был заявлен механизм vSphere APIs for IO Filtering (VAIO - как ноутбуки от Sony), который позволяет получать прямой доступ к потоку ввода-вывода (I/O Stream) гостевой ОС виртуальной машины. Несмотря на то, что об этой штуке писали достаточно мало, механизм VAIO в будущем будет способствовать созданию множества партнерских продуктов для решения самых разнообразных задач. VAIO основан на механике Storage Policy Based Management (SPBM), которая предназначения для управления хранением виртуальных машин.
Техническая реализация данного механизмв подразумевает использование драйвера VAIO (filter driver), который устанавливается на хосте VMware ESXi как пакет VIB и не требует установки никакого специального ПО в гостевой ОС виртуальной машины. Работает он на уровне VMDK-диска отдельной ВМ и позволяет не только получать данные из потока ввода-вывода, но и изменять его при течении данных в ту или другую сторону.
Это открывает возможности для применения VMware VAIO при решении следующих типов задач:
Encryption – стороннее ПО за счет использования механизма VAIO может на лету шифровать и расшифровывать поток данных от виртуальной машины. Таким образом на хранилище будут помещаться уже шифрованные данные. Гранулярность работы VAIO позволяет обслуживать данные идущие даже не от всей виртуальной машины, а только от одного приложения.
De-duplication - этот механизм уже использует решение VMware Virtual SAN. В реальном времени можно дедуплицировать данные, проходящие через драйвер и в таком виде уже класть на хранилище в целях экономии дискового пространства. Теперь это станет доступно и партнерам VMware.
Tiering - данные различной степени важности, критичности или классифицированные по другим критериям теперь можно класть на хранилища с разными характеристиками производительности и доступности (ярусы). Механизм VAIO тут поможет проанализировать характер данных и определить конечное их место назначения.
Analytics - теперь можно анализировать непосредственно поток данных от конкретной виртуальной машины и на основе этого строить множество различных решений, включая решения по кэшированию (например, такой продукт как CahceBox можно будет напрямую подключить к гипервизору). Затем можно, например, искать в трафике данные определенных приложений, либо, например, использовать механизм write-back кэширования.
На первом этапе запуска технологии VAIO компания VMware решила остановиться на двух путях ее имплементации:
1. Возможности кэширования данных на SSD-накопителях (write-back кэширование для операций записи). Дизайн-документ для API тут делала компания SanDisk, которая первой будет использовать VAIO в своих продуктах. Вот их презентация:
А вот технология write-back кэширования на стороне сервера с использованием механизма VAIO:
2. Возможности высокопроизводительной репликации. Реализация данного аспекта VAIO позволит получать прямой доступ к потоку ввода-вывода и сразу же передавать его на другой хост, не прибегая к дополнительным механизмам, которые сегодня используются для реализации техник репликации. На данный момент заявлено, что такой тип репликации будет поддерживать ПО EMC RecoverPoint, команда которого принимала участие в разработке техники VAIO.
Однако несмотря на все плюсы технологии vSphere APIs for IO Filtering, в ней есть и негативные стороны:
Во-первых, это вопрос надежности. Так как между виртуальной машиной и хранилищем есть дополнительное звено, которое может рухнуть, понижается и совокупная надежность платформы виртуализации.
Во-вторых, это вопрос производительности. Прослушка трафика посредством VAIO неизбежно создает нагрузку на аппаратные ресурсы хоста ESXi.
В-третьих, это вопрос безопасности. Представим, что я написал софт, который прозрачно шифрует и расшифровывает трафик отдельной виртуальной машины на хосте ESXi, после чего внедрил его в инфраструктуру предприятия, где все это произошло незаметно для пользователей и администраторов. Затем я просто убираю это ПО из гипервизора (например, при увольнении), после чего данные на хранилищах превращаются в тыкву, а компания сталкивается с серьезной проблемой.
В целом же, подход VMware в данном вопросе очень радует - она открывает партнерам возможности разработки собственных продуктов для решения задач пользователей, а значит предоставляет и неплохую возможность заработать.
Первые реализации механизма vSphere APIs for IO Filtering мы должны увидеть уже в первой половине 2015 года, когда выйдет обновленная версия платформы VMware vSphere 6.
Многие из вас знают компанию Login VSI, которая выпускает продукт Virtual Session Indexer (VSI), предназначенный для симуляции нагрузки и тестирования VDI-сред. Он уже успел стать стандартом де-факто при тестировании инфраструктуры виртуальных ПК у различных вендоров (например, см. тут). Напомним, что это коммерческое решение, а для бесплатного использования доступен продукт VSI Express.
Теперь компания решила подойти к тестированию VDI-инфраструктуры немного с другой стороны - на прошедшей конференции VMware VMworld 2014 была представлена бета-версия продукта Login VUM.
Это решение позволяет в реальном времени создавать нагрузку в виртуальном ПК для различных приложений (то есть открывать окна, выполнять некоторые операции), будто бы за этой виртуальной машиной работает реальный пользователь. Далее, если время выполнения стандартных операций превышает некоторые пороговые значения (например, приложение запускается слишком долго), Login VUM оповещает системного администратора о возникшей проблеме. Похожий способ используют в Водоканале Санкт-Петербурга - раков, обвешанных датчиками, держат в очищенной воде и измеряют их сердечный ритм, отклонения которого свидетельствуют об изменении качества подаваемой потребителям воды.
То есть, это способ мониторинга реальной производительности виртуальной среды посредством некой эталонной виртуальной машины, симулирующей реальную нагрузку. В веб-консоли можно наблюдать за значениями различных параметров этой машины, полученных в течение дня:
Само собой, Login VUM написан не с нуля, а основан на фреймворке Login VSI (технология измерений VSImax), который уже надежно зарекомендовал себя для задач тестирования инфраструктуры виртуальных ПК.
Пока продукт находится в стадии закрытой беты, но его уже можно будет скачать совсем скоро.
Также Login VSI представила свой графический фреймворк Login VSI: Graphics Framework, который позволяет отдельно тестировать чувствительные к производительности графики нагрузки в виртуальных ПК (такие как AutoCAD, Siemens NX или Photoshop). Фреймворк доступен для пользователей продукта Login VSI Pro.
Пример измерения фреймрейта для Автокада при увеличении числа сессий на хосте ESXi:
Видео о том, как выглядит процедура тестирования интенсивных графических нагрузок:
В результате тестирования данные не попадают в VSImax, так как администратору предлагается самостоятельно решить, какой фреймрейт подходит пользователям VDI-инфраструктуры для конкретного приложения и типа нагрузки.
На данный момент Login VSI: Graphics Framework доступен как публичная бета по этой ссылке.
Компания VMware выпустила интересный документ "Microsoft Exchange Server Performance on VMware Virtual SAN", в котором рассматривается случай тестирования нагрузки виртуальных серверов Microsoft Exchange размещенных в кластере Virtual SAN и работающих на серверах VMware ESXi.
В VMware использовали конфигурацию кластера VSAN из пяти узлов (Dell PowerEdge R720xd с процессорами Intel Xeon Processors E5-2650 и 128 ГБ памяти в каждом), на одном из узлов была машина с контроллером Active Directory, а для генерации нагрузки использовался отдельный клиент:
Детальная конфигурация стенда:
В качестве программной платформы использовался Exchange Server 2010, установленный в ОС Windows Server 2008 R2. На каждом хосте было размещено две виртуальных машины с Exchange - роли Mailbox и HUB.
С помощью Exchange Load Generator была сгенерирована нагрузка пользователей отсылающих и получающих письма. Для теста взяли 12 000, 16 000 и 20 000 пользователей с профилем нагрузки 150 отправляемых писем в день. Каждый почтовый ящик был инициализирован в размере 100 МБ.
При тестах Sendmail на указанном количестве пользователей выведен средний результат выполнения операций (Avg) и результат, уложившийся в 95 процентов опытов (95% latency).
Поскольку принято считать, что Latency до 500 миллисекунд для Exchange считается нормальной при отправке писем - то результаты тестов показывают, что такая конфигурация вполне жизнеспособна на десятках тысяч пользователей.
Больше подробностей можно узнать непосредственно из документа.
Вчера компания VMware выпустила обновление для платформы виртуализации VMware vSphere 5.5 Update 2, которое включает в себя апдейты составляющих компонентов - ESXi 5.5 Update 2 и vCenter Server 5.5 Update 2.
Основные новые возможности обновления:
Поддержка хостов ESXi с объемом памяти до 6 ТБ.
Агентское ПО VMware vShield Endpoint Thin Agent для поддержки взаимодействия с решениями vShield, которое устанавливается в гостевых ОС вместе с VMware Tools, теперь называется VMware Tools Guest Introspection plugin.
vCenter Server 5.5 U2 теперь поддерживает следующие внешние СУБД: Oracle 12c, Microsoft SQL Server 2012 Service Pack 1 и Microsoft SQL Server 2014.
Поддержка vCloud Hybrid Service (vCHS, переименован в vCloud Air) - теперь в vSphere Web Client на стартовой странице появился новый контейнер Hybrid Cloud Service, который содержит установщики vCHS и vCloud Connector.
Появились технические средства программы Customer Experience Improvement Program - теперь данные о конфигурации вашей виртуальной инфраструктуры на еженедельной основе могут передаваться на сторону VMware, чтобы она могла шпионить анализировать их и улучшать продукт.
Множественные исправления ошибок, о которых можно почитать в Release Notes.
При этом у данного релиза есть следующие особенности:
Начиная с vSphere 5.5 Update 2, операционные системы Windows XP и Windows Vista не поддерживаются для vSphere Web Client. Полный список поддерживаемых систем находится в VMware Compatibility Guide.
Так как Linux-платформы больше не поддерживаются механизмом Adobe Flash, то Web Client не поддерживается в ОС Linux. Но не поддерживается - не значит, что это прекратило работать.
VMware vCenter Server Appliance в vSphere 5.5 поддерживает гайдлайны по обеспечению ИБ DISA Security Technical Information Guidelines (STIG), поэтому перед использованием этого решения надо бы почитать VMware Hardened Virtual Appliance Operations Guide для того, чтобы узнать о новых стандартах безопасности и о том, как нужно работать, чтобы security-примочки не мешали.
В VMware vSphere 5.5 U2 больше не поддерживается СУБД IBM DB2 как база данных для vCenter.
Вся информация касательно установки VMware Tools в гостевых ОС теперь представлена в общей документации по VMware vSphere (начиная с версии 5.5).
vSphere Data Protection 5.1 не совместима с vSphere 5.5 по причине изменения рабочих процессов в vSphere Web Client. То есть, вместе с vSphere надо обновлять и VDP.
При обновлении компонентов виртуальной инфраструктуры посмотрите также Interoperability Matrix.
Скачать VMware vSphere 5.5 Update 2 можно по этой ссылке. Документация доступна тут.
Компания VMware на днях выпустила окончательную версию настольной платформы виртуализации для Mac OS VMware Fusion 7. Не знаю, как у вас, а на моем маке Fusion за два года не дала ни одного сбоя. Эти строки тоже пишутся в винде под VMware Fusion 6.
Итак, новые возможности VMware Fusion 7:
1. Обновление Fusion поддерживает новую Mac OS X Yosemite (в том числе в качестве гостевой ВМ). Визуальные улучшения включают в себя новую плоскую иконку, полупрозрачные элементы и поведение перехода в полноэкранный режим в стиле Yosemite.
Появились новые иконки в библиотеке, которые показывают состояние виртуальной машины (запущена или нет) в представлении списком.
2. Новое поколение виртуального программного обеспечения - Hardware Version 11. (VM > Settings > Compatibility).
VMware Fusion Pro поддерживает самую последнюю версию виртуального аппаратного обеспечения (virtual hardware), которое обеспечивает следующие возможности:
Поддержка функций процессоров семейства Haswell, включая поддержку инструкций AVX2 в виртуальной машине.
Новая виртуальная веб-камера, которая упрощает использование маковской вебки iSight в виртуальной машине Windows.
Поддержка HD-аудио формата 5.1 и технологии Bluetooth 4.0.
Обновленный USB-контроллер с поддержкой XHCI 1.0.
Новый подход к виртуальной видеопамяти - теперь она выделяется для каждой виртуальной машины отдельно (VM > Settings > Display). Не рекомендуют выделять гостевой ОС слишком много (будут глюки) и слишком мало видеопамяти (будут тормоза).
Возможность указать интегрированный или дискретный GPU на хосте для использования в виртуальной машине. На последних Mac Book Pro, которые могут иметь оба модуля, это может увеличить время работы от батареи.
Улучшение производительности машин до 60% (для легких нагрузок).
4. Обновленная поддержка конфигураций с несколькими мониторами, один из которых Retina. Также есть возможность определить поведение при переключении между Retina и обычным дисплеем.
5. Возможность настраивать горячие клавиши отдельно для каждой ВМ (VM > Settings > Keyboard & Mouse).
6. Улучшенная поддержка предрелизных версий Microsoft Windows.
7. Новый упрощенный способ установки VMware Tools под Windows 8 с использованием виртуального устройства USB CD virtual device.
8. Поддержка просмотра хостов VMware Workstation, VMware ESXi, VMware vSphere в библиотеке (в меню нужно выбрать File > Connect to Server). А именно:
Удаленная консоль с мышью и клавиатурой
Возможность выбрать CD, DVD, floppy devices или файлы на вашем Mac для подключения к ВМ.
Возможность включения и выключения ВМ, а также выбор виртуальной сети для адаптеров.
Перемещение виртуальных машин с Mac на удаленный компьютер (и наоборот) путем обычного перетаскивания.
Просмотр состояния удаленного сервера с помощью средств Activity Monitor.
9. Возможность удаленного управления виртуальными машинами на платформах VMware Workstation, VMware ESXi и VMware vSphere.
10. Возможность перенаправления аудиопотока гостевой ОС на конкретное аудиоустройство вашего Mac.
11. Улучшенная поддержка новых ОС Linux (в частности, Ubuntu 14.xx, RHEL 7, CentOS 7, Fedora 20 и Debian 8).
Не так давно мы писали о публичной бета-версии VMware vSphere 6, где каждый желающий мог скачать ее, посмотреть на список новых функций, но написать об этом не мог. На конференции VMware VMworld 2014 мораторий, по-сути, был снят - и теперь можно писать и рассказывать о новых возможностях платформы сколь угодно подробно.
Итак, что нового мы увидим в первой половине 2015 года (а именно тогда выйдет VMware vSphere 6):
1. Поддержка технологией Fault Tolerance до четырех виртуальных процессоров машины (4 vCPU).
Теперь технология непрерывной доступности VMware Fault Tolerance будет поддерживать виртуальные машины с 4 vCPU и объемом памяти до 64 ГБ.
Ранее для работы FT использовался механизм "Record-Replay" средствами технологии vLockstep, который воспроизводил инструкции основной машины на резервной. Теперь же используется техника Fast Checkpointing, которая позволяет организовать исполнение потока инструкций одновременно на обеих машинах. Если по какой-либо причине сетевое соединение между машинами замедляется, основная машина тоже начинает работать медленнее.
При этом теперь VMware Fault Tolerance можно будет конфигурировать для включенной виртуальной машины. Однако, по-прежнему, остаются следующие ограничения:
На хост ESXi можно иметь до 4 машин, защищенных технологией FT, при этом всего суммарно может быть защищено до 8 vCPU. Обратите внимание, что эти максимумы применяются суммарно к Primary и Secondary виртуальным машинам, расположенным на этом хосте.
Обязательно потребуется адаптер 10 Gb. Можно будет его разделять между различными типами трафика средствами NetIOC.
Нельзя использовать горячее добавление CPU или памяти для таких машин (Hot Add).
Если несколько vCPU затронуто технологией FT, то для таких машин не поддерживается Storage vMotion.
Кроме того, технику SMP-FT не поддерживают такие вещи, как vCloud Director, vSphere Replication, VSAN/vVols и vFlash.
При этом для таких машин полностью поддерживается VMware vMotion, а также они (как и раньше) защищаются кластером VMware HA - если с одной из машин что-то случается, то на другом хосте перезапускается реплика, которая уже становится Secondary VM.
Помимо этого, надо понимать, что SMP-FT вызовет падение производительности гостевой ОС, по оценкам VMware - это около 10-30% в зависимости от нагрузки.
Приятная новость - многопроцессорная FT будет поддерживать снапшоты виртуальных машин, а значит вы сможете делать их резервные копии средствами Veeam Backup and Replication или любым другим средством, поддерживающим vStorage APIs for Data Protection.
2. Улучшения горячей миграции виртуальных машин на большие расстояния (long distance vMotion).
О long distance vMotion мы уже писали вот тут, а впервые - вообще пять лет назад. И только сейчас обещания станут реальностью.
Теперь работающую виртуальную машину можно перемещать на расстояния, где RTT (Round Trip Time) в канале достигает 100 мс (неофициально поддерживается значение 150 мс). Это в 10 раз больше, чем было раньше.
И это - расстояние до 3000 километров (!). Теперь менеджерам датацентров открываются очень интересные стратегии по таким вариантам использования, как Follow the sun (машины работают там, где работают люди) и Follow the moon (машины работают ночью, когда электричество дешевле).
Кроме того, появились следующие улучшения технологии vMotion.
vMotion между разными серверами vCenter (нужна сеть на скорости 250 Mbps). Это происходит средствами протокола VMware Network File Copy (NFC).
Маршрутизируемый трафик vMotion (наконец-то).
vMotion между виртуальными коммутаторами vSwitch, а также Virtual Distributed Switch (VDS), поддерживаются режимы VSS to VSS, VSS to VDS, VDS to VDS (а вот VDS to VSS - нельзя).
средствами VMware NSX сетевые настройки машин могут быть перемещены в горячем режиме даже, если используется long distance vMotion.
3. Улучшенная производительность и новые возможности vSphere Web Client.
Здесь пока не сильно много деталей: появятся библиотеки контента (версии машин, темплейтов) и функции publish и subscribe для них. Также существенно будет улучшена производительность и уменьшен отклик при различных операциях.
Все это приходит в рамках концепции создания конвергентной инфраструктуры и развития парадигмы Software-Defined-Datacenter.
Здесь используются три основных элемента:
Vendor Provider (VP) – это плагин от производителя системы хранения данных, поддерживающий VVols через VASA API версии 2.0.
Storage Containers (SC) – это контейнеры на дисковом массиве, в которые упаковываются VMDK-диски каждой из машин. Это операбельная единица со стороны и системы хранения, и платформы VMware vSphere.
Protocol Endpoints (PE) – это средства управления томами на базе политик, предоставляемые администраторам. В них уже не будет понятий LUN и точек монтирования. Будет просто VVol, который можно привязывать и отвязывать от серверов ESXi/vCenter.
Все хранилища будут управляться на базе политик (сейчас это реализовано в VSAN):
5. Технология Virtual Datacenters.
Концепция виртуальных датацентров объединяет в себе пул вычислительных кластеров, кластеров хранилищ и политики их покрывающие. То есть это такой большой ресурсный контейнер, в котором есть зачатки интеллекта: он решает в какой из кластеров поместить виртуальную машину и на каком хранилище размещать виртуальные диски, чтобы это соответствовало определенным политикам.
По сути, это еще один уровень абстракции для крупных инфраструктур, в которых можно оперировать вот такими большими объектами из нескольких кластеров серверов и хранилищ.
6. Новые максимумы для хостов ESXi.
Нам обещают следующие параметры:
320+ pCPU
4+ TB Mem
4096+ vCPUs
32+ Nodes/Cluster
62TB+ VMDKs
Также с большой долей вероятности в VMware vSphere 6.0 мы увидим следующие возможности, о которых говорили на VMworld 2014:
Полная поддержка NVIDIA GRID vGPU - больше информации доступно тут.
Технология vSphere APIs for IO Filtering (VAIO) - о ней рассказано здесь.
Технология VMFork - метод по мгновенному клонированию запущенных виртуальных машин.
Больше подробностей о VMware vSphere 6 можно прочитать вот тут.
На проходящей сейчас в Сан-Франциско конференции VMworld 2014 компания VMware представила несколько интересных анонсов, которые (как всегда) открывают много возможностей для ИТ-инфраструктур различного масштаба. Одним из таких анонсов стал выпуск решения VMware EVO:RAIL, предназначенного для построения конвергентной инфраструктры.
На днях компания VMware выпустила долгожданный онлайн-сервис Virtual SAN Sizing Tool, который позволяет оценить необходимые аппаратные мощности, требующиеся для поддержания инфраструктуры хранилищ VSAN на базе локальных дисков серверов VMware ESXi.
В качестве исходных данных утилиты принимается конфигурация типовой виртуальной машины:
а также типовая аппаратная конфигурация хост-сервера ESXi:
Для виртуальных машин вам могут показаться непонятными параметры "Number of failures to tolerate" и "Number of disk stripes per object" - о них мы писали вот в этой статье.
В качестве результата расчетов будет выведена следующая информация:
Число хостов заданной конфигурации, необходимых для поддержания инфраструктуры VSAN.
Размер SSD-диска для дисковой группы HDD на хосте.
Максимумы по числу компонентов в кластере (машины, диски).
Полезная емкость кластера (зависит также от параметра FTT).
Емкость кластера по оперативной памяти.
Кроме того, дается брейкдаун по использованию дисковых емкостей, а также объем оперативной памяти под нужды Virtual SAN на хостах:
При расчетах используются следующие допущения:
Все хосты кластера имеют одинаковый аппаратный профиль, включая число HDD и SSD-дисков, объем памяти и количество ядер CPU.
Предполагается, что у всех виртуальных машин одинаковые требования к хранилищу: как по дисковой емкости и числу дисков, так и по нагрузке на СХД.
Предполагается, что у всех виртуальных машин одинаковая VSAN Policy, то есть параметры FTT и disk stripes per object.
Никаких кнопок для начала расчета нажимать не нужно - данные формируются "на лету". Приступить к работе с VMware Virtual SAN Sizing Tool можно по этой ссылке.
Почти три года назад мы писали про средство VMware I/O Analyzer, предназначенное для генерации нагрузки и анализа статистики ввода-вывода хостов VMware ESXi, доступное на сайте проекта VMware Labs. Не так давно вышло обновление этого средства, которое, как оказалось, живет и развивается.
VMware I/O Analyzer поставляется в виде виртуального модуля (готовой ВМ), предоставляющего администраторам следующие возможности:
Интегрированный фрейворк для тестирования производительности хранилищ средствами генераторов нагрузки.
Готовый к развертыванию виртуальный модуль (управляющая ВМ и "воркеры" - генераторы нагрузки).
Прост в настройке и возможность исполнения тестов на одном или нескольких хостах ESX/ESXi.
Возможность просмотра результатов производительности как на уровне хоста, так и на уровне гостевой ОС.
Возможность экспорта данных для последующего анализа.
Средства "повторения" нагрузки на хранилища путем ее воспроизведения из трейса ввода-вывода.
Возможность загрузки трейсов ввода-вывода для автоматического извлечения необходимых метрик.
Графическая визуализация метрик и результатов анализа производительности.
В обновленном VMware I/O Analyzer 1.6.x появились следующие возможности:
Улучшенный планировщик заданий ввода-вывода.
Сам виртуальный модуль теперь на платформе SLES 64-bit, а сервер на Tomcat 6.
Экспериментальная поддержка статистик клиента NFS.
Возможность использования непостоянной (non-persistent) конфигурации (без сохранения настроек).
Сама ВМ с I/O Analyzer теперь версии 7, что позволяет запускать и использовать ее в ESX/ESXi 4.x.
Улучшения на бэкэнде, позволяющие поддерживать до 240 и более генераторов нагрузки.
На самом деле с 2011 года много что изменилось в этом продукте, поэтому ознакомьтесь с юзер-гайдом, в котором есть история добавления фичей по версиям.
Скачать VMware I/O Analyzer можно по этой ссылке. Очень хорошо, что подобные утилиты не ограничиваются одним релизом, а развиваются и обрастают функционалом.
Если вы хотите, чтобы никто не делал vMotion конкретной виртуальной машины с конкретного сервера VMware ESXi, то нужно просто разослать письмо администраторам vSphere с просьбой этого не делать. Но есть еще один способ, который поведал нам Frank Denneman - хотя он тоже имеет ограниченные условия применения. Ну и не забываем, что есть способ путем задания правил механизма балансировки VMware DRS (однако, не у всех по лицензии DRS есть).
В этом способе есть один существенный минус - в то время, как он не позволяет пользователю двинуть виртуальную машину через vMotion вручную, смигрировать машину можно будет через перевод хоста ESXi в Maintenance mode, так как делается это не под аккаунтом пользователя, а под системной учетной записью (System). Но режим обслуживания используется редко, и хотя бы для ручных операций это можно будет сделать. Ну и имейте в виду, что механизм VMware HA также может перезапустить машину на другом хосте в случае сбоя, наплевав на все.
Итак, чтобы отключить vMotion для конкретной виртуальной машины, нужно создать новую роль (No-vMotion), для которой необходимо отключить привилегию по vMotion машины, назначатить эту роль администраторам и добавить пермиссию для виртуальной машины, указав юзеров с этой ролью (как работает этот механизм читайте здесь).
Итак, добавляем роль No-vMotion в vSphere Web Client:
1. Заходим в vCenter как administrator.
2.
Идем на домашний экран и переходим в Roles на экране Administration.
3. Выбираем действие создать роль (зеленый плюс).
4. Выбираем "All Priveleges", скроллимся до категории "Resource" и отчекиваем следующие привилегии,
Migrate powered off virtual machine
Migrate powered on virtual machine
Query vMotion
Далее добавляем пермиссию для виртуальной машины для нужного администратора/группы:
1. Выбираем "Host and Clusters" и находим нужную ВМ на вкладке Manage.
2. Выбираем пункт "Permissions" и кликаем на добавление пермиссии (зеленый плюс).
3. Нажимаем "Add" и выбираем пользователя или группу, которым мы хотим запретить vMotion этой виртуальной машины.
4. В правой части экрана выбираем роль "No-vMotion" и нажимаем "Ok".
Убеждаемся, что роль применена для данного пользователя к данному объекту (на остальные пермиссии это не повлияет):
Попробуем смигрировать эту виртуальную машину пользователем FrankD - видим, что опция "Migrate" загреена:
Но вот возможность перевода в Maintenance mode, к сожалению, по-прежнему активна:
Как вы знаете, автор этого сайта придерживается правила "лучше переставлять, чем обновлять" (когда речь идет о мажорных версиях продукта - см., например, вот тут и тут).
В VMware vSphere 5.0 компания VMware обновила свою кластерную файловую систему до версии VMFS 5. При этом в vSphere 5.x тома VMFS-3 поддерживаются, а также доступен апгрейд с третьей версии на пятую (напомним, что в пятой версии появилась поддержка дисков в 64 ТБ). Более подробная информация об апгрейде VMFS приведена в документе "VMware vSphere VMFS-5 Upgrade Considerations".
Так вот, апгрейженный том VMFS-5 имеет ограниченную функциональность в отличие от созданного заново тома, а именно:
Апгрейженный том продолжает использовать исходный размер блока (в новой версии VMFS 5.x размер блока унифицирован - 1 МБ). Это иногда может привести к чрезмерному потреблению места на диске (если много мелких файлов), но что самое неприятное - к падению производительности Storage vMotion.
Апгрейженный том не имеет таких возможностей как Sub-Block Size, увеличенное число файлов на хранилище и разметка GPT.
Обновленный том VMFS-5 продолжает иметь раздел, начинающийся с сектора 128, это может вызвать некоторые проблемы с выравниванием блоков. Новый раздел VMFS 5 начинается с сектора 2048.
Таким образом, получается, что лучше создать новый том VMFS-5, чем обновлять существующие тома VMFS-3. Но это все было давно, ну а вдруг у вас остались такие вот обновленные VMFS, из-за которых у вас иногда что-то работает не так?
Проверить, какой у вас том, можно в vSphere Client или vSphere Web Client. Смотрим размер блока:
Если он не 1 МБ - то это точно апгрейженный том, и его неплохо бы пересоздать. А вот если 1 МБ, то вовсе не факт, что это новый том (как раньше, так и сейчас был такой размер блока). В этом случае вам поможет вот этот скрипт, который выводит список всех томов VMFS и показывает, новый это том или апгрейженный.
Запустить этот скрипт можно таким образом:
1. Загружаем его и переименовываем его в check_vmfs.sh, убрав расширение .doc.
2. Копируем скрипт на виртуальный модуль vMA. Можно также запускать скрипт локально на сервере ESXi - для этого его туда надо загрузить через Veeam FastSCP или WinSCP.
3. Включаем демон SSH на хостах ESXi, где вы будете выполнять скрипт. (в vSphere Client нужно зайти в Configuration \ Software \ Security profile \ Services \ SSH).
4. Удаленно выполнить скрипт на серверах через SSH можно с помощью команды:
ssh root@<ESXi IP> 'ash -s' < ./check_vmfs.sh
Далее попросят пароль и будет выведен результат работы скрипта.
Здесь нужно смотреть на значение Sub Blocks, если Sub Blocks = 3968, то это апгрейженный VMFS-5, и его неплохо бы пересоздать. У нормального VMFS-5 значение Sub Blocks равно 32000.
Такое вот работающее правило "лучше переставлять, чем обновлять". Любители PowerShell могут также посмотреть вот эту статью.
Некоторое время назад компания VMware выпустила интересный документ "Understanding Data Locality in VMware Virtual SAN", касающийся локальности данных, то есть механизмов соблюдения временных и пространственных характеристик правильного чтения данных в целях оптимизации производительности кластера хранилищ Virtual SAN.
Мысль тут такая: локальность данных бывает двух типов:
временная (Temporal locality) - это когда есть вероятность, что данные, использованные сейчас, потребуются снова в ближайшее время (это актуально, поскольку в инфраструктуре виртуализации несколько машин на хосте часто используют одни и те же данные).
пространственная (Spatial locality) - ситуация, когда есть вероятность, что после чтения некоторой области данных потребуется прочитать и данные находящиеся рядом - то есть в соседних блоках на хранилище.
Так вот, в документе подробно разбирается, каким именно образом обеспечивается работа с этими особенностями локальности данных применительно к кэшированию данных на хранилищах SSD хостов VMware ESXi.
Примерами работы с локальностью данных являются следующие особенности кластеров Virtual SAN:
Каждый раз, когда виртуальная машина читает данные с хранилища, они сохраняются в кэше (Read Cache) на SSD-накопителе и эти данные могут быть востребованы очень быстро. Это работа с Temporal locality.
С точки зрения Spatial locality, при кэшировании данных в кэш сохраняется также и "окрестность" этих данных в рамках чанков по 1 МБ.
Virtual SAN имеет адаптивный алгоритм по вытеснению и сохранению данных в кэше - если данные используются редко, они выпадают с SSD-накопителя, а часто востребованные данные будут находиться там постоянно.
Virtual SAN распределяет экземпляры данных по разным хост-серверам ESXi и работает при чтении сразу с несколькими узлами, но при чтении одного диапазона логических адресов работа идет только с одной репликой. Обусловлено это двумя фактораи: во-первых, увеличивается шанс того, что читаемые данные уже находятся в кэше на SSD, а значит будут прочитаны быстрее, ну и, во-вторых, один блок данных всегда будет закэширован только на одном узле, а значит дорогое SSD-пространство не будет пожираться дубликатами блоков.
В общем документ очень интересный - почитайте. Там еще много полезной информации на эту тему.
RSS
